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Protocole de lancement d*une applic ation logicielle 
a distance et de reservation de res sources reseau 
avec gualite de service 

Avec I'avenement de I'echange d ' informations de 
toute nature, par 1 • intermediaire des reseaux de 
transmission, le probleme de la configuration, de 
Inoccupation et de 1 ' utilisation rationnelle de ces 
derniers est devenu d'une importance majeure, afin 
d» assurer une transmission de ces informations dans des 
conditions satisf aisantes . 

D'une maniere generale, la transmission de ces 
informations peut etre effectuee, par 1 • intermediaire de 
ces reseaux, en mode connecte ou en mode non connecte. 

Lors d'une transmission en mode connecte, une 
entite appelante ne peut emettre d ' informations vers une 
entite appelee sans avoir, au prealable, demande a cette 
derniere la permission de lui transmettre des blocs 
d' informations. Le processus de transmission en mode 
connects implique done la mise en auvre d'un etablissement 
de la connexion, succession de connexions multiples, d'un 
echange des blocs d' informations puis de la liberation de 
la connexion. C'est le cas, par exemple, de la 
communication par le reseau telephonique commute, RTC, ou 
par le reseau numerique a integration de services RNIS. 

Lors d'une transmission en mode non connecte, les 
informations sont transmises par routage vers une entite 
lointaine qui peut se trouver en etat d'activite ou de 
non-activite. En cas de non-activite, cette derniere est 
remplacee par une boite a lettres. Pour un tel mode de 
transmission, les caracteristiques des blocs de donnees 



transmises doivent etre connues et a chaque transmission 
il est necessaire de preciser les informations de controle 
qui seront necessaires pour que ces donn^es transmises, et 
les informations vehiculees par ces dernieres, arrivent a 
destination. En particulier, l*adresse de. I'entite 
lointaine, receptrice, et de l*entite emettrice, doivent 
dans ce but etre inserees dans le bloc de donnees 
transmises. C'est le cas en particulier de la transmission 
de messagerie electronique, de fichiers et d * applications 
pour lesquelles la communication en temps • reel n'est pas 
necessaire . 

A I'heure actuelle, les travaux publies sur le 
theme de la programmation, et la configuration, des 
reseaux • connectes ont essentiellement concerne les 
processus de programmation et de configuration avec 
signalisation. On rappelle, en particulier, que ces 
processus avec signalisation consistent, essentiellement, 
a transporter les commandes de connexion, encore appelees 
signalisation, par 1 ' intermediaire d'un reseau de 
signalisation dit reseau semaphore. 

Plus recemment, les Universites de Kansas et de Columbia 
(New York) aux Etats-Unis d'Amerique ont publie des 
travaux relatifs a la reservation de bande passante dans 
un reseau de transmission a l*aide du protocole de 
reservation de ressources GSMP, pour Generic Switch 
Management Protocol . 

Parmi ces travaux, on peut citer les articles ci-apres : 
1) "Realizing the MPEG-4 Multimedia Delivery Framework", 
IEEE Network Magazine pp. 35-45, Novembre/decembre 
1998. Special Issue on Transmission and Distribution 



of Digital Video, publie par J.F. HUARD, A. A. LAZAR, 
K.S. LIM et G.S. TSELIKIS ; 

2) "A ProgrammaJDle Transport Architecture with QOS 
Guarantee", IEEE Communications Magazine, Vol.36, 

5 No. 10, pp. 54-62, octobre 1998 publie par J.F. HUARD 

et A. A. LAZAR ; 

3) "The IEEE p. 1520 Standards Initiative for Programmable 
Network Interfaces", IEEE Communications Magazine, 
Vol.36, No. 10, pp. 64-70, octobre 1998, publie par 

10 J. BISWAS, A. A. LAZAR, J.F. HUARD, K.S. LIM, 

S. MAHJOUB, L.F. PAU, M. SUZUKI, S. TORTENSSON, W.WANG 
et S. WEINSTEIN ; 

4) "Programming Telecommunication Networks", IEEE Network 
Magazine pp. 8-18, septembre/octobre 1997, publie par 

15 A. A. LAZAR. 

En outre, des procedures de demande 

d'etablissement d'une connexion a travers un reseau par 
1 ' intermediaire d'un navigateur "web" ont fait I'objet de 
travaux. Parmi ceux-ci, on peut citer : 
20 5) 1* article intitule "Session Control for Broadhand 
Multimedia Services using the HTTP Protocol'', ATM 
Forum, fevrier 1997, publie par GOTA LEIJONHUFVUD 
Ericsson Telecom AB. 
Enfin, les procedures RMI {Remote Method Invocation) et 
25 HTML (Hyper Text Marked Language) sont connues en 
environnement JAVA pour lancer des applications dans une 
architecture client-serveur sur un reseau non connecte. 

Les procedures mentionnees precedemment donnent 
satisfaction, mais elles doivent utiliser le meme reseau 
30 pour assurer la transmission des flux d' informations de 
1' application. A titre d'exemple, il n'existe pas dans les 
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procedures precitees de moyens d'indiquer vers le reseau 
utilise la valeur et le type de qualite de service requis. 
En outre, dans ,les procedures precitees, il n'existe a 
priori aucun couplage permettant d'assurer le lancement 
5 d'une connexion d'un reseau connecte, ni a fortiori une 
application, ce dernier etant distinct et independant du 
reseau non connecte. 

La presente invention a pour objet de remedier aux 
inconvenients et limitations des procedures de 1 ' art 
10 anterieur par la mise en oeuvre d'un protocole de lancement 
d * une application logicielle a distance et de reservation 
de ressources reseau avec qualite de service, un terminal 
appelant etant ainsi mis en mesure de lancer une 
application a distance sur un terminal appele lorsque ces 
15 terminaux sont relies sur un reseau connecte. 

Un autre objet de la presente invention ^ est en 
outre la mise en ceuvre d'un protocole de lancement d'une 
application logicielle a distance et de reservation de 
ressources reseau avec qualite de service dans lequel, 
20 prealablement au lancement effectif. de 1 ' application, le 
terminal appelant a effectue, par reservation, des 
connexions a partir d'un reseau non connecte. 

Un autre objet de la presente invention est 
egalement, apres realisation de la connexion par le reseau 
25 connecte entre le terminal appelant et le terminal appele, 
la mise en ceuvre d'un protocole permettant la mise en 
ceuvre d'une communication avec un debit a qualite de 
service garanti sur le reseau connecte. 

Un autre objet de la presente invention est enfin 
30 la mise en oeuvre d'un protocole de lancement d'une 
application logicielle a distance et de reservation de 



ressources reseau avec qualite de service plus 
particulierement destine a la gestion de communications 
visiophoniques a partir d'un meme ensemble integre au 
niveau du terminal appelant. 

5 Le protocole de lancement d'une application 

logicielle a distance et de reservation de ressources 
reseau avec qualite de service entre un terminal appelant 
et un terminal appele, objet de la presente invention, est 
remarquable en ce qu'il consiste a transmettre, a partir 

10 du terminal appelant vers le terminal appele, une requete 
de reservation de connexion, par 1 ' intermediaire d'un 
serveur et d'une transmission par reseau non connecte et a 
etablir, entre le terminal appelant et le terminal appele, 
un processus de reservation de ressources reseau avec 

15 qualite de service, par echange de messages par 
1* interm^diaire de la transmission par le reseau non 
connecte. Sur acceptation de la reservation de ressources 
reseau par le serveur est etabli, sur le meme reseau 
physique support du reseau non connecte, par 

20 1' intermediaire d'un reseau de commande, un reseau 
connecte entre le terminal appelant et le terminal appele. 
Le reseau connecte constitue la ressource reseau avec 
qualite de service pour executer 1 ' application logicielle 
a distance entre le terminal appelant et le terminal 

25 appele. 

Le protocole objet de la presente invention est 
destine a la mise en ceuvre a distance d' applications 
logicielles de tout type avec reservation de qualite de 
service, mais il est plus particulierement destine a des 
30 applications de visioconf erence pour lesquelles la gestion 



de 1 'occupation de bande passante des reseaux connectes en 
assurant L' execution est primordiale . 

Le protocole objet de la presents invention sera 
maintenant expose dans la description ci-apres en liaison 
5 avec les figures en facilitant la comprehension dans 
lesquelles : 

- la figure la represents, sous la forme d'un 
organigramme fonctionnel, les etapes de mise en oeuvre du 
protocole objet de la presente invention ; 

10 - la figure lb represents un mode de realisation 

particulier preferentiel du protocole objet de la presente 
invention dans le cas ou le reseau non connecte est le 
reseau IP, pour Internet. Protocol, et ou le reseau 
connecte .esit^le reseau ATM-^; 

15 - - la ., figure ^ Ic rep^resente -a ^.titre illustratif 

1 • architeciture • relative^ des^ reseaux-* connecte et non 
connecte dans' le mode^ de»v?realdsation de? la figure lb ; 

- la ^ figure 2 ' represente, a titre d*exemple 
illustratif/ un detail de mise en oeuvre du protocole objet 

20 de la presente invention, dans un mode de mise en oeuvre 
preferentiel dans lequel les messages de requete de 
reservation de connexion et de processus de reservation 
sont etablis en environnement JAVA ; 

- les figures 3a et 3b representent des pages 
25 ecrans affichees par le moniteur du terminal appelant 

respect ivement du terminal appele dans le cas d'une 
application de visioconf erence . 

Le protocole deip- lancement d'une application 
logicielle a distance et de reservation de ressources 
30 reseau avec qualite de service, objet de la presente 
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invention, sera maintenant decrit en liaison avec la 
figure la et les figures suivantes. 

D-une maniere generale, on indique que le 
protocole objet de la presente invention est destine a 
etre mis en CBUvre entre un terminal appelant, note TA, et 
un terminal appele, not6 TB. Bien entendu, le terminal 
appelant et le terminal appele sont equipes des ressources 
necessaires afin d'^changer des messages d' informations 
sous forme de fichiers et de preference sous forme de 
pages ecrans permettant 1 ■ instauration d'un dialogue 
interactif entre le terminal appelant TA et le terminal 
appel6 TB. 

En reference a la figure la, on indique que, suite 
a une 6tape de d6but dans laquelle le terminal appelant TA 
et le terminal appele TB sont necessairement physiquement 
interconnect^s a un reseau susceptible de mettre en 
communication ces derniers, le terminal appele TB etant 
fonctionnellement ind6pendant du terminal appelant TA, le 
protocole objet de la presente invention consiste, a 
I'etape A, a transmettre & partir du terminal appelant TA 
vers le terminal appele TB une requete de reservation de 
connexion, cette requete etant not^e R«c et etant 
transmise par 1 ■ intermediaire d'un serveur S et d'une 
transmission par un reseau non connects. De par la 
transmission de cette requete par reseau non connecte, 
cette transmission implique les conditions de transmission 
prec^demment mentionn^es dans la description, relativement 
a la transmission de donnees ou de messages d • information 
sur le reseau non connects. 

suite a l'6tape A precitee, le protocole objet de 
la presents invention consiste, en une 6tape B, a 6tablir 
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entre le terminal appelant TA et le terminal appele TB, un 
processus de reservation de ressources reseau avec qualite 
de service. D'une maniere generale, on indique que ce 
processus de reservation permet a 1 ' ut ilisateur du 
5 terminal TA de definir certains parametres relatifs aux 
ressources reseau avec qualite de service, ainsi qu'il 
sera decrit ulterieurement dans la description. 

Conformement a un aspect remarquable du protocole 
objet de la presente invention, on indique que le 

10 processus de reservation est etabli par echange de 
messages par 1 ' intermediaire du serveur et de la 
transmission par reseau non connecte precedemment 
mentionne relativement a l*etape A. 

Sur acceptation de la reservation de ressources 

15 reseau par le serveur, le terminal appele precite ou 
1 * utilisateur de • ce dernier etant susceptible d'accepter 
1' execution de 1 ' application, le protocole objet de la 
presente invention consiste, a I'etape C, a etablir, de 
preference sur le meme reseau physique support du reseau 

20 non connecte, par 1 ' intermediaire d'un reseau de commande 
RC, un reseau connecte entre le terminal appelant TA et le 
terminal appele TB. On rappelle ainsi que, lorsque le 
reseau connecte est etabli, la transmission de messages 
d ' information entre le terminal appelant TA et le terminal 

25 appele TB satisfait aux conditions prealablement 
mentionnees dans la description relativement a la 
transmission de messages d ' information sur un reseau 
connecte . 

Ainsi, le reseau connecte constitue la ressource 
30 reseau avec qualite de service permettant d'executer 



1' application logicielle a distance entre le terminal 
appelant et le terminal appele. 

D'une maniere generale, on indique que pour 
realiser la mise en oeuvre du protocole objet de la 
5 presente invention, il est necessaire que le reseau 
connecte destine a transporter les flux d ' informations 
avec qualite de service soit commande de maniere externe,. 
la notion de commande externe couvrant a la fois la mise 
en ceuvre d'un reseau de commande, le reseau RC, permettant 
10 de configurer les connexions successives du reseau 
connects ou, le cas echeant, d'un systdme de traduction 
entre les messages transmis par le reseau non connecte 
afin d'effectuer la reservation des ressources et une 
signalisation existante telle que definie precedemment 
15 dans la description. 

Differents modes de realisation specifiques seront 
maintenant decrits en liaison avec les figures lb et Ic, 
lesquelles visent a definir une architecture 
preferentielle des systemes de reseaux connectes, 
20 respectivement de reseaux non connectes mis en CEUvre pour 
assurer la conduite du protocole de lancement d'une 
application logicielle a distance et de reservation de 
ressources reseau avec qualite de service conforme a 
1' objet de la presente invention. 
25 D'une maniere generale, en reference a la figure 

lb, on indique que les etapes consistant a transmettre la 
requete de reservation de connexion Rrc et a etablir entre 
le terminal appelant et le terminal appel6 un processus de 
reservation de ressources reseau avec quality de service 
30 sont de preference realisees a partir du serveur. 
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De meme, en reference a la figure Ic, on indique 
que de maniere particulierement avantageuse, le serveur 
peut etre constitue par un-. serveur "web". Dans ces 
conditions, les^ etapes consistant a transmettre la requete 

5 de reservation de connexion et a etablir entre le terminal 
appelant TA et le terminal appele TB un processus de 
reservation de ressources reseau avec qualite de service 
peut consister alors en 1' envoi de messages HTML, pour 
Hyper Text Marked Language. 

10 En reference aux figures lb et Ic, on indique que 

dans ce mode de realisation pref erent iel , le protocole 
objet de la presente invention permet de controler des 
liens d'un reseawt ATM -«ra partiir d'un resea-u^^ IP, le reseau 
ATM constituant le reseau^ connectjs et-^ le reseau IP le 

15 reseau non connecite-.^ 

Ai^nsd'^ que^^repEesente^iem figure lb, on indique que 
des termi^nauxv^ terminal-*? appelant- TA et termi^nM appele TB, 
disposen-t' bi*en«» entendu d' une ^ carte . d ' intei?.connexion en 
reseau de * type^^IP ■ et d' une^ cax-te d ' inteisconnex^ion en 

20 reseau de type ATM, afin d'effectuer le transport des flux 
d* informations a qualite de service ou, le cas echeant, de 
disposer des deux piles de protocole sur la meme carte 
d' interconnexion ATM ainsi qu'il est represente sur la 
figure lb. 

25 Dans ce cas, les deux reseaux, reseau IP non 

connecte et reseau ATM connects, sont constitues sur le 
meme^ support physique. En particulier, les applications 
IP, c ':es>t-a-di:ire ' les messages*' HTML ou anad-ogue, sont 
transportees sur une emulation d'un.resea-u local LAN, pour 

30 Local Area Network, et les messages ATM peuvent etre 
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transmis dans la machine directement ou aprSs la couche 

d' adaptation AAL. 

Ainsi, en reference a la figure lb, on indique que 
les deux piles de protocols sont supportees par le mSme 

5 support physique. 

En reference k la figure Ic, lorsque la connexion 
vers un serveur, tel qu'en particulier un serveur "web", 
est 6tablie a partir du terminal appelant TA, le dialogue 
peut s'etablir entre le terminal appelant precite et le 
,0 serveur par 1 • intermediaire du protocols HTTP d'un 
navigateur "web" pour le transfert des messages et le cas 
ech6ant de programmes, sous-programmes d' execution ainsi 
qu'il sera d^crit ulterieurement dans la description. 
Ensuite, le serveur peut alors lancer des ordres de 
,5 connexion, ainsi que represents sur la figure Ic, les 
ordres de connexion etant lances a un reseau de commande 
par 1- intermediaire d'un protocols IP CORBA, le reseau de 
commande comportant un BUS CORBA vers des stations 
generatrices de liens ATM. On indique que. de maniere non 
20 limitative, en reference S la figure Ic, la configuration 
du reseau ATM est rSalisee a partir d'une plate-forme de 
programmation repartie, toute autre solution telle que la 
signalisation par un agent tiers pouvant etre egalement 
envisagee . 

En reference S la figure Ic, on indique que, pour 
rfealiser les connexions sur le rfeseau ATM, c'est-a-dire 
pour configurer le reseau connects ainsi que represents 
sur la figure precitee, le protocole utilise entre le 
^6seau ds commands pr6cedemment mentionnfe RC et le reseau 
ATM, constituant en fait le reseau de transport ds 
!• application avec qualite ds ssrvics, peut etre realisfe 
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par 1 * intermediaire d'un protocole GSMP, pour Generic 
Switch Management Protocol . 

On comprend ainsi qu'au niveau du reseau connecte 
constituant le reseau de transport precite,, ce;*reseau peut 

5 etre constitue en differents sous-reseaux, sous-reseau 1, 
sous-reseau 2, de maniere non limitative, les liens ATM 
entre terminal appelant TA et terminal appele TB 
permettant bien entendu de realiser 1 ' interconnexion de 
ces derniers en des lieux quelconques. 

10 Une description plus detaillee d*un exemple 

specif ique de mise en ceuvre du protocole objet de la 
presente invention, dans le cas ou le reseau non connecte 
est un reseau IP et ou le serveur est un serveur "web" par 
exemple, sera maintenant donnee- en liaison avec la figure 

15 2. 

Ainsi ^ que represente sur la figure precitee, les 
etapes consistant a transmettre la requete deTrreservation 
de connexion et a etablir le processus de reservation de 
ressources reseau avec qualite de service, c*est-a-dire 

20 les etapes representees en figure la aux points A, B, 
peuvent consister au moins a transmettre 1) du terminal 
appelant TA au serveur "web" une demande de connexion et, 
sur connexion du terminal appelant TA au serveur precite, 
a fournir 2) au terminal appelant TA une page d* entree. La 

25 fourniture d'une page d' entree au terminal appelant TA 
n'est pas decrite en detail figure 2, car une telle 
operation est une operation classique, lors d'un acces par 
un terminal a un serveu-r, selon le protocole de 
transmission par reseau IP. 

30 Suite a la fourniture de la page d' entree, le 

protocole objet de la presente invention consiste en une 
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etape 3) dans laquelle le terminal appelant precede a un 
telfechargement dans les memoires constitutives de ce 
dernier a partir du serveur, et en particulier du serveur 
"web", d'un sous -programme de selection de paramfetres de 
qualite de service. Ainsi, le terminal appelant, h partir 
de ce sous-programme, sera en mesure, par 1 ■ intermediaire 
du guidage de 1 ' utilisateur de ce terminal appelant, de 
selectionner les parametres de transmission des 
informations relatives a 1 • application a executer. 

L'etape 3) precit6e est alors suivie d'une etape 
3a) representee par une fleche en boucle fermee au niveau 
du terminal appelant TA consistent a etablir, a partir du 
terminal appelant precite et du sous -programme de 
selection, un choix de parametres de qualite de service. 

Les 6tapes 3) et 3a) precedemment mentionnees sont 
alors suivies d'une etape 4) consistant, apres avoir saisi 
les paramStres de la communication et de quality de 
service desires, a transmettre du terminal appelant TA au 
serveur, serveur "web", le choix des parametres de qualite 

20 de service retenu. 

Suite a l'etape 4), il est alors possible 
d- etablir, a partir du choix des paramfetres de qualite de 
service retenu, la reservation des ressources de reseau 
connecte constituant les ressources reseau avec qualite de 
service prec6demment mentionnees dans la description. La 
reservation des ressources pr6cit6e est etablie a partir 
du serveur, serveur "web", vers le reseau ATM pr6c6demment 
decrit en liaison avec les figures lb et Ic par 
1- intermediaire du reseau de commande RC. 

Ainsi, k la fin de l'6tape 4), le reseau de 
commande RC 6tablit une reservation de ressources sur le 
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reseau ATM entre le terminal appelant TA et le terminal 
appele TB, 

Suite a 1 * etablissement de la reservation des 
ressources de reseau- connecte,^ le protocole objet de la 
5 presente invention peut consister avantageusement a 
transmettre, en une etape. 5a) , a partir du terminal 
appelant TA vers le terminal appele TB, une requete 
d' execution d ' application, cette requete d' execution 
d ' application comportant au moins un code d ' identification 

10 du terminal appelant TA. On comprend bien sur que 1 ' etape 
de transmission de la requete d' execution d ' application 
peut alors etre realisee sur le reseau non connecte bien 
que la reserve t.ion- des ressou-rces de reseau connecte ait 
ef f ectivement et,e. ef fectuee et le reseau*.. connecte ait 

15 ainsi ete -etabli . D'une ^mand^ere generale,* on indique que 
la requete d'exeeutiion d 'application compprte -au moins un 
code dVi dent if reaction du terminal appelant TA. Suite a 
I'etape 5a)" pree-itee, le pr^ot-ocole objet^= de la presente 
invention consiste, en une etape 5b) , a etabldr au niveau 

20 du terminal appele TB un processus de gestion de la 
requete d' execution d * application . Sur la figure 2, pour 
cette raison, le processus de gestion realise a 1' etape 
5b) est represente par une boucle fermee au niveau du 
terminal TB. 

25 Dans un mode de realisation particulier 

preferentiel non limitatif, le processus de gestion 
represente a 1' etape 5b) peut comporter avantageusement, 
sur - ref-us pa»i?* le terminal- appe-le TB'^ der- la requete 
d' execution de 1 ' application, une etape de transmission 

30 par 1 ' intermediaire du circuit non connecte vers le 
terminal appelant TA d*un message de re jet de la requete 
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d- execution d • application et d'incitation du terminal 
appelant TA a liberer la reservation de connexion. Sur la 
figure 2, on indique que I'etape de transmission du 
message de rejet de la requSte d' execution est ref§rencee 
5 5c) . 

Au contraire, sur a<?ceptation par le terminal 
appel6 TB de la requete d' execution, une etape de 
transmission par 1 • intermediaire du circuit non connecte 
au terminal appelant d'un message d' acceptation de la 
10 requete d' execution d' application et de lancement de cette 
application est realises. Sur la figure 2, I'etape 
precit^e de transmission d'un message d' acceptation de la 
requete d' execution d' application est not6e 5d) . 

Au contraire, en 1' absence de reponse du terminal 
15 appele TB pendant une duree pr6determinee, absence de 
reponse a la requete d' execution d'application, le 
protocole objet de la presente invention consiste a 
effectuer la transmission, en une etape 5e) , suite a la 
duree pr6determin6e precitee par 1 ■ intermediaire du 
20 circuit connecte vers le terminal appelant TA d'un message 
d' absence du terminal appele TB. D'une maniere generale, 
on indique que sur la figure 2, les stapes 5c), 5d) et 5e) 
sont globalement designees par r6ponse de visio, visio 
designant de maniere gen^rique une application d^diee a la 
25 visioconference ainsi qu'il sera decrit ulterieurement 

dans la description. 

Le protocole de lancement d'une application 
logicielle a distance et de reservation de ressources 
reseau avec qualite de service, objet de la presente 
30 invention, peut etre mis en oeuvre, en ce qui concerne la 
requete de reservation de connexion et le sous-programme 
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de selection de parametres de qualite de service, au moyen 
de sous-programmes , designes communement par appliquettes 
ou encore applets en environnement JAVA. 

Dans ces conditions, on indique que I'etape de 

5 telechargement dans le terminal appelant a partir du 
serveur d'un sous-programme de selection de parametres de 
qualite de service, peut consister avantageusement en le 
chargement d'une appliquette JAVA. 

Enfin, lors de la fin de 1' execution de 

10 1 'application/ c'est-a-dire lors de la fin de la 
transmission de messages d ' information par le reseau ATM, 
le terminal appelant TA et le terminal appele TB terminent 
leur application localemen*t de-^ ma^ndere- semblable a la 
terminal son d'un appjel telephonique classique par exemple 

15 ou d * une *communicat-ion sur le -reseau RNIS. 

Suite a .la..-terminaison de cetCe communication, le 
terminal- appellant TA, lequel. a etab.li la connexion, est 
alors incite 'a -effectuer une -operation de- deconnexion 
permettant en- fait de liberer a I'etape 7) les, ressources 

20 aupres du serveur "web" precite du reseau ATM. La gestion 
de 1' ensemble est done complete, le reseau ATM etant alors 
totalement libere et pret pour une nouvelle 
reconfiguration ulterieure. 

Une description plus detaillee d* elements 

25 specifiques du protocole, objet de la presente invention, 
lorsque 1 ' application est dediee a une application de 
visioconf erenee, sera maintenant donnee en liaison avec 
1 e s:j*f i'^ u r e stt 3 a'^^e t^ 3 b . 

Dans une telle situation, on. comprend que les 

30 informations video relatives a la visioconf erence sont 
transmises par le reseau ATM et que dans ce but, le sous- 
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programme de selection de parametres de qualite de service 
constitue par une appliqoette JAVA permet le choix des 
parametres d'abonnS, de bande passante et de 
multidif fusion pour Multicast. En ce qui concerne la mise 

5 en oeuvre et la transmission d • appliquettes JAVA, on 
preferera le mecanisme RMI, pour Remote Method Invocation. 
cree par la societe JAVASOFT, en raison de 1 • inadaptation 
du protocole RPC, pour Remote Procedure Code, des systfemes 
objet distribu6s. Ce mecanisme RMI a pour objectif : 

10 - de supporter 1' invocation distante des objets JAVA ; 

- d'int6grer le module objet distribue dans 
I'environnement JAVA de faQon naturelle tout en gardant 
la s6mantique objet du langage ; 

- de rendre simple le d^veloppement d • applications 

15 distribuees ; 

- de preserver la security et la surete fournies par 
1 • environnement JAVA precite. 

On indique que le mecanisme RMI precitfe fait appel 
aux notions client/serveur valables pour un appel. Le 
,0 mecanisme RMI permet en fait d'invoquer a distance un 
objet JAVA, ce qui permet de satisfaire a deux des trois 
points critiques mentionnes precedemment, ^ savoir : 

- la dfependance de la mise en CEuvre de ce mecanisme, ce 
mecanisme RMI utilisant en fait I'adresse IP pour 

25 retrouver le serveur RMI distant ; 

- en outre, un service de visioconf6rence impose, au 
niveau de chaque terminal, terminal appelant TA et 
terminal appele TB, que le terminal appele TB soit sous 
tension et connects et qu'un serveur RMI existe en 

30 tache de fond sur chacun des terminaux precites. 
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Au cours d*une communication, le terminal appelant 
TA est a la fois client et serveur RMI, et le terminal 
app.el<e TB est-^ .serveur RMI, meme si -le code est le meme sur 
chacun des terminaux precites. Dans ces conditions, le 
5 service de • visioconf erence precedemment mentionne n'est 
done pas completement indej^endant du^ terminal mais il a 
I'avantage d'etre securise car les seules actions 
possibles sur chaque terminal distant sont celles definies 
dans 1' interface cote serveur. 

10 Afin de mettre en oeuvre le service de 

visioconf erence precite, il est toutefois necessaire de 
prevenir le terminal appele TB de la requete d' execution 
d ' application precedemment ment ionnee- dans la description. 

Dans le cadre de la ^mise en. oeuvre du protocole, 

15 objet de la present e invention, en environnement JAVA, une 
solution satisf aisante consiste a introduire, au niveau du 
terminal appele, * une bolte de 'dialogue JAVA^winvoquee a 
distance . 

Dans ces conditions, les memes references 
20 chiffrees correspondant aux etapes de mise en ceuvre du 
protocole objet de la presente invention telles que 
represente en figure 2 maintenant dediees a une 
application de visioconf erence , les etapes successives 
correspondantes sont donnees ci-apres : 
25 1) le terminal appelant TA se connecte au serveur "web" 
de ressources ; 

2) une page HTML est fournie par ce dernier- au terminal 
appel-ant TA. Le . serveur "web" contient les 
informations necessaires au service. II assure la 
30 correspondance entre le nom et I'adresse IP du 
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terminal appelant TA de itianiere similaire aux listes 
de diffusion dans les courriers electroniques ; 
3) le terminal appelant TA telecharge 1 ' appliquette 
JAVA, laquelle permet de choisir les parametres de 
communication tels que abonne bande passante, 

multidif fusion pour multicast ainsi que mentionne 
precedemment, cette liste n'etant pas limitative. 
L'appliquette JAVA precitee, ainsi que represente en 
figure 3a, comporte une page ecran affichee au niveau 
du terminal appelant TA et comportant au moins deux 
boutons de selection, un bouton de selection 
"Connexion" /"Deconnexion" ainsi qu ' un bouton de 
reglage du debit voulu pour assurer la transmission 
des donnees de visioconf erence . Les autres parametres 
peuvent servir pour la commande externe. Le bouton de 
reglage de debit est designe par "Debit Kb" sur la 
figure 3a. 

De maniere particulierement avantageuse, on indique 
que le bouton de selection "Connexion"/ " Deconnexion" 
est un bouton a fonction reattribuable . Selon un 
aspect particulierement avantageux, au bouton de 
selection "Connexion" est allouee, suite a la 
reservation de ressources de reseau avec qualite de 
service, une fonction de synchronisation entre la 
commande externe du reseau et le lancement de 
1 ' application de visioconf erence . Un tel mode 
operatoire permet une synchronisation entre la 
commande externe de reseau et le lancement proprement 
dit de 1 • application de visioconf erence car elle 
evite ainsi de lancer 1 ' application precitee avant la 
reservation des ressources du reseau ATM sans 
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lesquelles 1 * appl ication ne peut bien entendu 
f onctionner . 

4) L'appui sur le bouton "Connexion" a l*etape A) 
declenche le retour vers le serveur "web" de I'ordre 
5 d • etablissement de la connexion. Dans ces conditions, 

le serveur "web" pas^se^ I'ordre de^, reservation au 
reseau de commande RC et ce dernier etablit une 
reservation de ressources ATM entre le terminal 
appelant TA et le terminal appele TB par allocation 

10 d'un chemin virtuel VP, pour Virtual Path, et d'un 

canal virtuel VC, pour Virtual Channel, par terminal 
apres calcul de 1' operation de routage. Dans 
I'exemple - precite,; la gestion du reseau est 
distribuee en^ reference a la .figure Ic a I'aide du 

15 protocole CORBA-% afin d'obtenir une- meilleure 

eff icaeite * lors de la , commande.'^" desiw&commutateurs 
assurant la connexion^ pour constituer-* le reseau 
connecte . *' 

5a) lors de- I'etape- consideree, 1 ' appliquette JAVA 
20 precedemment mentionnee comporte en outre une page 

ecran affichee au niveau du terminal appele TB. Cette 
page ecran comportant deux boutons, un bouton 
d* acceptation, note "Accepte", et un bouton de refus 
de lancement de 1 ' application, bouton note "refuse". 
25 action realisee a 1 ' etape 5a) precitee met ainsi en 

attente le terminal appelant avec un message du type 
"Appel en» cours" et previent de cette maniere le 
te-rminal-^ appele TB d'une demande-* de*^- visioconf erence 
par 1 • intermediaire de la bolte de dialogue, le cas 
30 echeant combinee a une sonnerie, cette boite de 

dialogue lui indiquant l*identite du demandeur. Sur 



21 

la figure 3b, on indique que le mot "Visio" designs 
1* application de visioconf erence de maniere 
generique, "Karnak" designant arbit rairement 

I'identite du terminal appelant. La boite de dialogue 
precitee telle que representee en figure 3b peut 
avantageusement etre constituee par une application 
JAVA lancee au moyen du mecanisme RMI precite et 
permet ainsi au terminal appele TB de repondre au 
terminal appelant TA en fonction de sa decision. On 
comprend bien sur que dans de telles conditions, la 
decision est prise par 1 ' utilisateur du terminal 
appele TB. 

La gestion de 1 ' acceptation ou du refus peut alors 
etre realisee selon plusieurs choix a I'aide des deux 
boutons precedemment mentionnes en liaison avec la 
figure 3b, boutons d ' acceptation ou de refus. 
L' utilisateur du terminal appele peut ainsi realiser 
les actions suivantes : 

a) il peut refuser la visioconf erence demandee par 
appui sur le bouton "Refuse", cette action ayant 
pour effet de retourner alors un code permettant 
d'indiquer au demandeur que son correspondant ne 
desire pas la visioconf erence et que 1 * utilisateur 
du terminal appelant TA a en charge de lib^rer les 
ressources precedemment reservees. C'est I'etape 
5c) de la figure 2. 

b) Le terminal appele peut accepter la 
visioconf erence demandee par appui sur le bouton 
"Accept^", le code retour correspondant etant 
renvoye et les applications de visioconf erence 
etant alors lancees simultan^ment sur les deux 
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terminaux, terminal appelant, terminal appele, au 
moyen du mecanisrae RMI . C * est I'etape 5d) de la 
figure 2. 

c) Le terminal appele TB est connecte, mais il ne 
repond pas apres la fin d'un module retardateur 
"timer" dont la duree peut etre fixee de 15 a 20 
secondes par exemple. Dans de telles conditions, 
on indique alors 1 ' absence de 1 * utilisateur du 
terminal appele TB au terminal appelant TA. Le 
timer precite peut avantageusement etre declenche 
au niveau du terminal appele TB lors du lancement 
de la boite de dialogue JAVA. C'est I'etape 5e) de 
la figure 2. 

Lors de la fin de la communication, c'est-a-dire lors 
de la fin de 1 ' application de visioconf erence, les 
deux abonnes utilisateurs des terminaux, terminal 
appele TA et terminal appele TB, terminent leur 
application localement comme au telephone par 
exemple. Le terminal appelant qui a etabli la 
connexion doit alors terminer celle-ci par un appui 
sur le bouton "Deconnexion" ; 

L* appui par 1 * utilisateur au niveau du terminal 
appelant TA sur le bouton "Deconnexion" dont la 
fonction n'a pas ete reattribuee permet alors de 
liberer les ressources apr^s la fin de la 
visioconf erence et de la fin de la communication. Le 
mecanisme de deconnexion peut alors etre similaire a 
celui de la connexion mais avec 1 ' ordre de liberer 
les ressources au lieu de les reserver. 



23 



10 



15 



RFVENDICATIONS 

1. Protocole de lancement d'une application 
logicielle a distance' et de reservation de ressources 
reseau avec qualite de service, entre un terminal appelant 
et un terminal appele, caracterise en ce qu'il consiste : 

- a transmettre, a partir du terminal appelant vers le 
terminal appele, une requete de reservation de 
connexion, par 1 Vintermediaire d'un serveur et d'une 
transmission par reseau non connecte ; 

- a etablir, entre le terminal appelant et le terminal 
appele, un processus de reservation de ressources 
reseau avec quality de service, par echange de messages 
par 1' intermediaire de ladite transmission par reseau 
non connecte, et sur acceptation de ladite reservation 
de ressources reseau par ledit serveur, 

- a etablir, sur le meme reseau physique support du 
reseau non connecte, par 1 ' intermediaire d » un reseau de 
commande, un reseau connecte entre ledit terminal 
appelant et ledit terminal appele, ledit reseau 
connecte constituant ladite ressource reseau avec 
qualite de service pour executer ladite application 
logicielle a distance entre ledit terminal appelant et 
ledit terminal appele. 

2. Protocole selon la revendicat ion 1, caracterise 
en ce que ledit serveur etant constitu^ par un serveur 
"web", lesdites Stapes consistant a transmettre la requete 
de reservation de connexion et a etablir entre le terminal 
appelant et le terminal appele un processus de reservation 
de ressources reseau avec qualite de service consiste en 
30 1' envoi de messages HTML. 
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3. Protocole selon I'une des revendications 1 ou 
2, caracterise en ce que lesdites etapes consistant a 
transmettre la requete de reservation de connexion et a 
etablir ledit processus de reservation de ressources 
5 reseau avec qualite de service consiste au moins : 

a , transmettre dudit terminal appelant audit serveur une 
demande de connexion ; et, sur connexion dudit terminal 
appelant audit serveur, 

a fournir audit terminal appelant une page d* entree ; 
*0 - a charger dans ledit terminal appelant, a partir dudit 
serveur, un sous-programme de selection de parametres 
de qualite de service ; 
- a etablir, a partir dudit terminal appelant et dudit 
sous-programme de selection, un choix de parametres de 
15 qualite de service ; 

a transmettre, dudit terminal appelant audit serveur 
ledit choix de parametres de quality de service ; 
a etablir, a partir du choix des parametres de qualite 
de service, la reservation des ressources de reseau 
20 connecte, constituant les ressources reseau avec 

qualite de service. 

4. Protocole selon I'une des revendications 1, 2 
ou 3, caracterise en ce que, suite a 1 • etablissement de la 
reservation des ressources de reseau connecte, celui-ci 
25 consiste en outre : 

a transmettre, a partir du terminal appelant, vers le 
terminal appele, une requete d' execution d ' application, 
ladite requete d' execution d ' application comportant au 
moins un code d ' identification du terminal appelant ; 
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- a etablir, au niveau dudit terminal appele, un 
processus de gestion de la requete d' execution 
d* application. 

5. Protocole selon la revendication A, caracterise 
en ce que ledit processus de gestion comporte : 

- sur refus, par ledit terminal appele, de la requete 
d* execution de 1 » application, une etape de 
transmission, par 1 ' intermediaire dudit circuit non 
connecte, audit terminal appelant d'un message de rejet 
de ladite requete d' execution d ' application et 
d'incitation du terminal appelant a lib^rer ladite 
reservation de connexion ; 

- sur acceptation par ledit terminal appele de la requete 
d' execution, une etape de transmission, par 
I'intermediaire dudit circuit non connecte, audit 
terminal appelant d'un message d ' acceptation de ladite 
requete d' execution d ' application et de lancement de 
cette application ; 

- sur absence de reponse dudit terminal appele pendant 
une duree predeterminee, transmission, suite a cette 
dur^e d^terminee par 1 ' intermediaire du circuit non 
connecte, vers ledit terminal appelant d'un message 
d' absence du terminal appele. 

6. Protocole selon I'une des revendications 2 a 5, 
caracterise en ce que la requete de reservation de 
connexion et le sous-programme de selection de parametres 
de qualite de service sont constitues par des appliquettes 
en environnement JAVA. 

7. Protocole selon la revendication 6, caracterise 
en ce que, pour une application logicielle constitute par 
une session de visioconf erence , transmise par le reseau 
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ATM, ledit sous-progranmie de selection de parametres de 
qualite de service constitue par une appliquette JAVA 
permet le choix des parametres d'abonne, de bande 
passante, demultidif fusion. 
5 8. Protocole selon la revendication 1, caracterise 

en ce que ladite appliquette JAVA comporte une page ecran 
affichee au niveau du terminal appelant comportant au 
moins deux boutons de selection, un bouton de selection 
"connexion" / "deconnexion" et un bouton de reglage du debit 
10 de transmission. 

9. Protocole selon la revendication 8, caracterise 
en ce que ledit bouton de selection 
"connexion"/"deconnexion" est un bouton a fonction 
reattribuable, au . bouton- de selection "connexion" etant 

15 alloue, suite a ,,la reservation de ressources de reseau 
avec qualite de servicey une" fonction de:^' synchronisation 
entre la commande ,externer"du _ reseau . et. le ' lancement de 
1 ' application de visioconf erence . 

10. Protocole selon la revendication 8 ou 9, 
20 caracterise en ce que ladite appliquette JAVA comporte en 

outre une page 6cran affichee au niveau dudit terminal 
appele comportant deux boutons, un bouton d ' acceptation et 
un bouton de refus de lancement de 1 ' application . 
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